Traditionally database query optimization does not take into account system hardware energy consumption but rather tries to optimize the query runtime performance by considering data access plan alternatives and comparing their CPU (central processing unit) and I/O (input-output) (runtime) costs. While almost all queries involve accessing data from physical database objects like tables and indexes (on disc storage, for example), there are queries that are truly I/O bound (as compared to CPU bound), i.e. the data access cost comes mainly from those I/O operations and the involved CPU time for other query related computations is minimal.
The I/O situation can change, though, when the query is either run multiple times or the database objects are accessed from different tasks concurrently or within the same shorter timeframe. The effect of those multiple accesses to the same disc storage is that the underlying storage management system usually caches the requested data in memory and thus does not require a physical access for the next request for the same storage area. This often makes the query CPU-bound, since there is very little or no real disc activity anymore in this “warm” (cached) state.
Existing query optimizers usually just optimize the query plan on “cold” (not cached) costing for the involved database objects and, if at all, only react to a change from “cold” to “warm” by considering re-optimizing the query based on runtime statistics from previous query runs. It is beneficial to incorporate energy cost considerations of those different access methods while maintaining acceptable query performance by making energy-cost-aware decisions between alternative access methods.